An object-based storage system (Object-Based Storage System) is a distributed storage system and is formed by a plurality of object-based storage devices OSDs (Object-based Storage Devices). The OSDs are interconnected through a network, and an OSD may also be called a node in the object-based storage system. In the object-based storage system, an object (Object) is a most basic stored content unit, and the object includes data and attribute information of the data. The data refers to content stored in the object, for example, a video file, a music file, or the like; and the attribute information of the data is, for example, a size of a file, version information, or the like.
For reliability of a stored object, one object is generally stored in different OSDs. In this way, even if a part of OSDs are faulty, a read operation and a write operation for the object are not affected, thereby improving data reliability. Because a same object needs to be stored in different nodes after being backed up with many copies, and in other words, the object is stored across a plurality of OSD nodes, these backups of data may also be called copies. In order to ensure a consistency requirement of object-based storage, a write operation on an object needs to be ensured by a transaction. A transaction may be understood as a group of operations for a data change. In the group of operations, the data will not be changed unless all the operations are successful. This ensures that copies of a same object in different OSDs are the same, thereby avoiding that a part of the copies are changed but the other part of the copies are not changed.
A transaction is a set of a series of operations, these operations are often executed in parallel by a plurality of nodes so that data distributed in a plurality of nodes is transformed from a consistent state to another consistent state (in a distributed object-based storage system, this means a same object in the plurality of nodes has a same version number); and either all or none of the operations constituting the series of operations are executed, thereby maintaining consistency of a data state in the nodes. In a non-storage field, a situation in which a transaction is required also exists.
The existing two-phase commitment protocol (Two-phase Commitment Protocol, 2PC) can ensure atomicity of distributed transaction commitment. The 2PC protocol appoints an OSD of a distributed transaction as a coordinator (Coordinator), and appoints all other OSDs as participants (Participants). Only the coordinator has determining power of committing or revoking a transaction; and after making a conclusion of committing or revoking a transaction, the coordinator sends the conclusion to the participants. If the conclusion is to commit the transaction, a Commit message is sent; and if the conclusion is to abort the transaction, an Abort message is sent. Each participant receives the conclusion of the coordinator and executes an operation in a local database of the participant according to the conclusion; and the participants may also propose, to the coordinator, an intention of revoking or committing a sub-transaction.
When the participants are waiting for a conclusion of the coordinator, if the coordinator is faulty, the participants will wait a long time for the conclusion of the coordinator. During a waiting period, a transaction of each participant cannot be completed, and an occupied resource cannot be released, resulting in blocking. In order to avoid blocking, the prior art proposes a state acknowledgment technology, where a participant queries a transaction state of other participants to confirm whether the participant needs to execute the transaction. However, in this method, interactive processes between participants are excessive, resulting in reduction of system performance.
Even if the coordinator is not faulty, how to draw a transaction conclusion by reading information of the participants is also a problem to be solved.